1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for mapping objects within an object-oriented environment to a database schema and for automatically generating a database schema.
2. Description of the Related Art
Multi-Tier Enterprise Computing Systems
Java 2 Enterprise Edition (“J2EE”) is a specification for building and deploying distributed enterprise applications. Unlike traditional client-server systems, J2EE is based on a multi-tiered architecture in which server side program code is divided into several layers including a “presentation” layer and a “business logic” layer.
FIG. 1 illustrates an exemplary J2EE application server 100 in which the presentation layer is implemented as a Web container 111 and the business layer is implemented as an Enterprise Java Bean (“EJB”) container 101. Containers are runtime environments which provide standard common services 119, 109 to runtime components. For example, the Java Naming and Directory Interface (“JNDI”) is a service that provides application components with methods for performing standard naming and directory services. Containers also provide unified access to enterprise information systems 117 such as relational databases through the Java Database Connectivity (“JDBC”) service, and legacy computer systems through the J2EE Connector Architecture (“JCA”) service. In addition, containers provide a declarative mechanism for configuring application components at deployment time through the use of deployment descriptors (described in greater detail below).
As illustrated in FIG. 1, each layer of the J2EE architecture includes multiple containers. The Web container 111, for example, is itself comprised of a servlet container 115 for processing servlets and a Java Server Pages (“JSP”) container 116 for processing Java server pages. The EJB container 101 includes three different containers for supporting three different types of enterprise Java beans: a session bean container 105 for session beans, an entity bean container 106 for entity beans, and a message driven bean container 107 for message driven beans. A more detailed description of J2EE containers and J2EE services can be found in RAGAE GHALY AND KRISHNA KOTHAPALLI, SAMS TEACH YOURSELF EJB IN 21 DAYS (2003) (see, e.g., pages 353-376).
Persistence and Enterprise Java Beans
The information systems of a modern day enterprise (such as a corporation or government institution) are often responsible for managing and performing automated tasks upon large amounts of data. Persistent data is that data that “exists” for extended periods of time (i.e., it “persists”). Persistent data is typically stored in a database so that it can be accessed as needed over the course of its existence. Here, complex “database software” (e.g., such as DB2, Oracle, and SQL Server) is often used to read the data and perhaps perform various intelligent functions with it. Frequently, persistent data can change over the course of its existence (e.g., by executing a series of reads and writes to the data over the course of its existence). Moreover, multiple items of different persistent data may change as part of a single large scale “distributed transaction.”
FIG. 2 illustrates the manner in which persistent data is managed in current J2EE environments. Session beans 255-257 comprise the high level workflow and business rules implemented by the application server 100. For example, in a customer relationship management (“CRM”) system, session beans define the business operations to be performed on the underlying customer data (e.g., calculate average customer invoice dollars, plot the number of customers over a given timeframe, . . . etc).
Session beans typically execute a single task for a single client during a “session.” Two versions of session beans exist: “stateless” session beans and “stateful” session beans. As its name suggests, a stateless session bean interacts with a client without storing the current state of its interaction with the client. By contrast, a stateful session bean stores its state across multiple client interactions.
Entity beans are persistent objects which represent data (e.g., customers, products, orders, . . . etc) stored within a database 223. Typically, each entity bean 252 is mapped to a table 260 in the relational database and, as indicated in FIG. 2, each “instance” of the entity bean is typically mapped to a row in the table (referred to generally as an “object-relational mapping”). Two different types of persistence may be defined for entity beans: “bean-managed persistence” and “container-managed persistence.” With bean-managed persistence, the entity bean designer must provide the code to access the underlying database (e.g., SQL Java and/or JDBC commands). By contrast, with container-managed persistence, the EJB container 101 manages the underlying calls to the database.
Each EJB consists of “remote home” and/or “local home” interface and “remote component” and/or “local component” interface, and one class, the “bean” class. The home interface lists the methods available for creating, removing and finding EJBs within the EJB container. The home object is the implementation of the home interface and is generated by the EJB container at deploy time. The home object is used by clients to identify particular components and establish a connection to the components' interfaces. The component interfaces provides the underlying business methods offered by the EJB.
Entity Bean Deployment
A “deployment descriptor” is an XML file (named “ejb-jar.xml”) that describes how entity beans are deployed within the J2EE application server 100. For each CMP entity bean, the deployment descriptor defines “persistent fields” which represent and store a single unit of data, and “relationship” fields which represent and store references to other entity beans. Relationship fields are analogous to foreign keys used in relational database tables. Relationships between entity beans may be defined as “one-to-one” where each entity bean is associated with a single instance of another entity bean, “one-to-many” where each entity bean is associated with many instances of another entity bean, or “many-to-many” where entity bean instances may be related to multiple instances of each other.
An exemplary object model of three entity beans is illustrated in FIG. 3 and an exemplary deployment descriptor describing the three entity beans is illustrated in FIGS. 4a-c. The entity beans include a product entity bean 303 representing one or more products, an order entity bean 301 representing a business order and a customer entity bean 302 representing a customer. As indicated in FIG. 3, a many-to-many relationship exists between the product bean 303 and the order bean 301 (i.e., many different product may be used in many different orders). Similarly, a one-to-many relationship exists between the customer bean 302 and the order bean 301 (i.e., an individual customer may make multiple orders).
The container-managed persistence (“CMP”) fields of the product bean 301 include product Name, Product ID, and Price (identifying the name product identification code and price, respectively, of each product). The CMP fields for the order bean 302 include Order ID, Order Date, Credit Approved (indicating whether the user's credit card company approved the order) and Order Status; and the CMP fields for the customer bean 303 include social security number (SSN), Age, First Name and Last Name of the customer.
The deployment descriptor illustrated in FIGS. 4a-c includes separate sections 401-403 representing and describing the CMP fields for each entity bean 301-303, respectively. For example, section 401 includes four entries 410-413 (identified by the <cmp-field> XML tags) identifying each of the order entity bean's CMP fields (i.e., Order ID, Order Date, Credit Approved, and Order Status). Entity bean sections 402-403 include similar entries identifying CMP fields. In addition, for each entity bean, one particular CMP field is identified as the primary key field using the <primkey-field> tag 414-416 (e.g., Order ID for the order bean 301).
A <relationships> section 405 of the deployment descriptor (see FIG. 4b) defines the relationships between each of the entity beans 301-303. Each entity bean relationship is defined under a separate <ejb-relation> tag 406, 407. For example, the one-to-many relationship between the order bean 301 and the customer bean 302 is described by setting the <multiplicity> tag 430 associated with the order bean 301 to “many” and setting the <multiplicity> tag 431 associated with the customer bean 302 to “one.” Similar descriptions are provided under <ejb-relation> tag 407 to define the many-to-many relationship between the order bean 301 and the product bean 303.
Thus, the standard deployment descriptor, ejb-jar.xml, defines the various CMP fields for each entity bean and the relationships between entity beans. However, no standard mechanism exists for specifying how the various CMP fields and relationships are mapped to relational database tables. In addition, no standard mechanisms exist for generating a database schema which matches the object schema of an existing object-oriented application.